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REMARKS 

This is an appeal of the Final Rejection dated February 28, 2006 of Claims 1-20. A 
Notice of Appeal from this Final Rejection was timely filed on August 28, 2006. 
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L REAL PARTY IN INTEREST 

The real party in interest in this appeal is the assignee, TANDBERG TELECOM AS. 

IL RELATED APPEALS AND INTERFERENCES 

Appellants' legal representatives and the assignee are aware of no appeals which will 
directly affect or be directly affected by or have any bearing on the Board's decision in this 
appeal. 

IIL STATUS OF THE CLAIMS 
In the Official Action dated February 28, 2006, Claims 1-20 were rejected under 35 
U.S.C. § 103(a) as being unpatentable over Nataraian et al. (U.S. Patent No. 6,505,244, 
hereinafter Nataraian) in view of Evans (U.S. Patent No. 5,694,524) and Yates et al. (U.S. 
Patent No. 6,330,586, hereinafter Yates). 

IV, STATUS OF THE AMENDMENTS 

Appellants' amendment was filed on December 7, 2005 and was entered. Appellants 
file herewith an amendment under 37 C.F.R § LI 16 so as to materially reduce issues to be 
considered for appeal and so that Claims 1 1-20 comply with 35 U.S.C. § 101. This last 
amendment awaits disposition as of the filing of this Appeal Brief 

V. SUMMARY OF THE CLAIMED SUBJECT MATTER 
Briefly recapitulating, Claim 1 is directed to a method for modeling video 
teleconferencing network reliability. The method includes obtaining historical data for 
multiple video conferences, and storing the historical data in a call history table (e.g., item 
102 in Figure 3). The historical data is referenced to video teleconferencing equipment 
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vendor or model identification infonnation (e.g., specification, page 7, line 30 - page 8, line 
22; Figures 3-5). The method also includes executing a modeling algorithm (e.g., item 101 in 
Figure 6; specification, page 9, lines 1-7) that produces a model representing the historical 
data, analyzing the model to identify characteristics associated with xmdesirable outcomes for 
the video conferences (e.g., specification, page 9, line 16 - page 10, line 2), and configuring a 
video teleconferencing network to avoid at least one of the identified characteristics 
associated with undesirable outcomes (e.g., specification, page 10, line 15 - page 11, line 6). 
Independent Claims 1 1 and 20 are directed to a corresponding computer program product and 
data processing system. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The first issue is whether Nataraian or Yates discloses or suggests Appellants* 
historical data referenced to video teleconferencing equipment vendor or model identification 
information (e.g., specification, page 7, line 30 - page 8, line 22; Figures 3-5). 

The second issue is whether Nataraian discloses or suggests Appellants' obtaining 
historical data for multiple video conferences, and storing this multi-conference historical 
data in a call history table. 

The third issue is whether Nataraian discloses or suggests Appellants' steps of 
executing a modeling algorithm (e.g., item 101 in Figure 6; specification, page 9, lines 1-7) 
that produces a model representing the historical data, analyzing the model, and configuring a 
video teleconferencing network based on the analysis. 

VII- ARGUMENT 

Natarajan describes a feedback-based adaptive network wherein at least a portion of 
the network elements report operating information relating to network conditions to a 
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centralized data store. The information which is reported to the data store is analyzed by a 
policy engine which includes a plurality of application specific plug-in policies for analyzing 
selected information fi-om the data store and for computing updated control information based 
upon the analysis of the information. The updated control information is fed back to selected 
network elements to thereby affect operation of the selected elements. 

Nataraian does not disclose or suggest Appellants' call history table or Appellants' 
steps of executing a modeling algorithm that produces a model representing the historical 
data, analyzing the model, and configuring a video teleconferencing network based on the 
analysis. 

A. Both Nataraian and Yates do not disclose or suggest Appellants* historical data 
referenced to video teleconferencing equipment vendor or model identification 
information. 

As acknowledged in the Official Action,' Nataraian d oes not disclose or suggest 
Appellants' historical data referenced to video teleconferencing equipment vendor or model 
identification information. To cure this deficiency, the Official Action points to Yates,^ 
column 5, line 66 - column 6, line 12. However, this passage of Yates merely amplifies an 
earlier discussion of benefits (not data) associated with various disclosed object-oriented 
software modules and states "Other potential benefits of the access arrangements for an 
individual user might include the following: single contact point for services from different 
vendors; easy invocation and use of services from different vendors; consistent presentation 
of services across different vendors; integrated accounting and charging for a service set 
supplied by multiple vendors^ security fi-om unauthorised invocation and use of services; 
privacy fi-om unauthorised access to service usage and service content information." This 
statement of benefits is not "historical data referenced to video teleconferencing equipment 

* Official Action, paragraph 3 a. 
^ Official Action, paragraph 3b. 
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vendor or model identification information," let alone Appellants' historical data stored in a 
call history table or Appellants' model representing the historical data. That is, these 
enumerated benefits are not data at all. 

Furthermore, the objects discussed in Yates serve to hide vendor specific features and 
anomalies, rather than to store and model vendor specific features. That is, Yates ' recitation 
of vendor-related user/system benefits (i.e., 1) single contact point for services fi-om different 
vendors; 2) easy invocation and use of services from different vendors; 3) consistent 
presentation of services across different vendors; and 4) integrated accounting and charging 
for a service set supplied by multiple vendors) are benefits only because any vendor specific 
data is hidden or harmonized with a generic model. Nothing about the objects of Yates 
suggest storing or modeling vendor specific features. 

B. Nataraian does not disclose or suggest Appellants' obtaining historical data for 
multiple video conferences, and storing this multi-conference historical data in a 
call history table. 

The Official Action refers to Figure 15 of Nataraian for a disclosure of Appellants' 
storing this multi-conference historical data in a call history table.^ This figure shows an 
example of a flow diagram for a data store event handler reporting procedure 1500. 
Procedure 1500 may be implemented via the event handling entity 272 residing at data store 
252. One responsibility of event handler 272 is to continually monitor the data store for new 
or updated control information which has been generated by the network elements or by the 
policy engine 254. When event handler 272 detects the occurrence or availability of a new 
control parameter, it notifies the event server 270 which distributes the event notification 
message onto the appropriate network elementCs)."* Thus, data store 252 stores data relative 

^ Official Action, paragraph 3a, 
Nataraian. column 25, lines 27-55. 
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to events used by or relating to event handler 272. However, this event data is not 
Appellants' historical data for multiple video conferences. That is, the event data of 
Nataraian has no persistence from one process to another. Said differently, the event data of 
Natarajan pertains to a single video teleconference, not to multiple video teleconferences as 
required by Appellants' claims. 

To understand this point, it is first necessary to identify what constitutes event data in 
Natarajan . While the word "event" is used 247 times in Nataraian , the term 'event' is never 
explicitly defined. However, an implied definition may be derived from the following 
examples of events disclosed in Natarajan : 

• ...notification for specified events, such as, for example, the availability of 
updated control information at data store 252.^ 

• Yet another purpose of the event handler is to monitor specified network 
elements, and report the detection of specified events (e.g. detected errors) to 
event server 270. In an alternate embodiment, the event handler is statically pre- 
configured so that when it is initialized, it automatically monitors a specified 
network element for specific types of events and reports detected events to event 
server 270. For example, when an error is detected by network element 204A, the 
event handler 274A will report the error to event server 270 to be forwarded to 
other network and/or control elements (e.g. policy engine 254), which may be 
interested in this type of information.^ 

• Event handler 272 continually monitors the data store for updated control 
information and other events .^ 

• The policy engine may either repeatedly poll the data store for updated network 
data, or rely on an event service to be notified that a change in the network 
conditions has occurred .^ 

• The application specific policy may be automatically loaded upon on initialization 
of the policy analysis procedure, or may be loaded subsequently upon the 
occurrence of an event, such as, for example, the execution of a specific user 
application .^ 

• The event handler 274A may initially consult a local configuration file (not 
shown) in order to determine which events the network element is to register for at 
the event server 270.^^ 



^ Nataraian . column 10, lines 21-25. 

* Natarajan , coliunn 10, lines 41-57. 

^ Natarajan, column 10, line 67 - column 1 1, line 1, 

* Nataraian, column 13, line 66 - column 14, line 2. 
^ Nataraian , column 15, lines 42-46. 

Natarajan, column 19, lines 25-28. 
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However, none of these events are related to multiple video teleconferences as 

required by Appellants' claims. That is, there is no indication that an error of one process 

(e.g., conference) to be used in another process (e.g., conference). There also is no rationale 

for an error of one process (e.g., conference) to be used in another process (e.g., conference). 

Similarly, there is indication that any of the other examples of events described in Nataraian 

arising in a first process (e.g., conference) would be applicable to a second process (e.g., 

conference). 

The Official Action also cites to column 7, lines 12-43 of Nataraian for a disclosure of 

Appellants' claimed storing of historical data of multiple conferences in a call history table. 

Appellants traverse this finding and note that the cited passage of Nataraian recites: 

"The feedback-based adaptive network of the present invention utilizes a 
technique wherein at least a portion of the network elements (e.g., 204A, 
204B, 208A, 208B, etc.) report network information relating to network 
conditions to a centralized data storage entity (e.g., data store 252). The 
reported data corresponds to information relating to the current condition or 
status of each of the reporting network elements in the network . The 
information which is reported to the data store 252 is analyzed by a policy 
engine 254. The policy engine 254 includes a plurality of application specific 
plug-in policies for analyzing application specific information from the data 
store and for computing updated control information based upon the analysis 
of the information . The updated control information may include any type of 
information, parameters, and/or actions which may be used to affect the 
operation of one or more network elements. The updated control information 
is then fed back to selected network elements to thereby affect operation of 
the selected elements and/or network. Typically, when the operation of a 
network element has been affected, its corresponding operating parameters 
and/or operating information will change. The changed operating parameters 
are then reported to the data store 252 and analyzed by the policy engine 254. 
The policy engine may then generate new or updated control information or 
parameters for affecting the operation of selected elements in the network. In 
this way, the network of FIG. 2 is configured to adapt to changing conditions 
in the network by providing a dynamic feedback mechanism. Using this 
dynamic feedback mechanism, selected network elements may be 
dynamically and automatically reconfigured to cause the performance of 
various aspects of the network to conform with desired performance criteria." 

Appellants first submit that the above-cited passage of Nataraian discloses nothing related to 
call history or a call history table. The only data apparently stored in this passage is "changed 
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Operating parameters are then reported to the data store 252." However, neither the recited 
changed operating parameters nor any other information (e.g., the control information and 
parameter information analyzed by the policy engine 254) is call history data, let alone call 
history data of multiple video conferences. 

First, as with the previous discussion of 'events', there is no indication that "current 
conditions" of equipment involved in one process (e.g., conference) are used in another 
process (e.g., conference). There also is no rationale for "current conditions" of equipment 
involved one process (e.g., conference) to be used in another process (e.g., conference). The 
process, events and models of Natarajan are directed exclusively to single video 
teleconferences, and not to management of multiple video teleconferences via use of 
historical data. 

Indeed, the only reference to a video teleconference in Nataraian is found relative to 
the example of Figures 16-18 ("Using the network illustrated in FIG. 16, various aspects of 
the present invention will now be described by way of example in which a video 
teleconference is established between userl (1602) and user2 (1620). The video 
teleconference example is described in greater detail with respect to FIGS. 17 and 18 of the 
drawings.").^* A review of the entirety of column 29, line 36 - column 33, line 62 reveal that 
the events monitored relate to a single video teleconference, not to multiple video 
teleconferences as required by Appellants' independent claims. Thus, at best, Natarajan 
discloses the storing of historical (event) data relative to the management of a single ongoing 
video teleconference. Natarajan does not disclose or suggest storing historical (event) data 
from one video teleconference to be used in a second video teleconference, as required by 
Appellants' citation of "multiple conferences." 



" Nataraian. column 29, lines 53-58. 
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C. Nataraian does not disclose or suggest Appellants' steps of executing a modeling 
algorithm that produces a model representing the historical data, analyzing said 
modeL and configuring a video teleconferencing network based on said analysis. 

The passages cited in the Official Action relative to Appellants' modeling refer to the 
previously discussed Figures 16-18 of Nataraian .'^ These figures provide an illustrative 
example of how various network elements interact with each other to form a feedback-based 
adaptive network. In particular, Figure 17 shows a flow diagram of how the feedback-based 
network of Figure 16 adapts to changing conditions in the network as a video teleconference 
is initiated between user 1 and user 2. A video teleconference application between user 1 and 
user 2 is one example of a user application which may require additional bandwidth in order 
to provide a satisfactory level quality for using the application to service multiple users across 
the network. Thus, the video teleconference example may be abstracted to be applied to any 
user application requiring additional network resources to provide a satisfactory level of 
quality for the application to run over a network environment. When a video teleconference 
begins between users 1 and 2, the network may respond by initiating one or more bandwidth 
policies at the policy engine 1654 and may also respond by initiating one or more 
policies/procedures at the monitor system 1662.^^ 

At 1704 the fi-ame relay CIR policy is initiated at the policy engine 1654 if this policy 
has not already been initiated. While the firame relay CIR policy is being initiated by the 
policy engine at 1704, a CIR policy monitor procedure is concurrently initiated (1716) at 
monitor system 1662, if this procedure has not already been initiated. At 1706, each of the 
links a, b, c, d of Figure 16 reports the nvmiber of packets dropped on that link to data storage 
1652. The fi-ame relay CIR policy at the policy engine 1654 uses this data to generate (1708) 
updated CIR parameter values for each of the respective links. The updated CIR paretmeter 
values generated by the policy engine are then written (1710) into the data store 1652. Once 

Official Action, paragraph 3a. 

Nataraian, column 29, line 36 through column 30, line 66. 
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the appropriate network elements have been notified of changed network conditions, each of 
the network elements may retrieve a respective updated CIR parameter information from the 
data store 1652 and then update its configuration using the updated CIR parameter 
information.'^ 

In the CIR policy monitor procedure of FIG. 17, the quality monitor system 1662 
(FIG. 16) may concurrently and continuously monitor the effectiveness of the frame relay 
CIR pohcy implemented by the policy engine. In the example of FIG. 17, the effectiveness of 
the frame relay CIR poUcy is measured by analyzing the nxmiber of packets dropped at each 
of the respective links A, B, C, D, and comparing this data to predetermined criteria or 
guidelines. Thus, for example, at 1718, the reported number of packets dropped for links A, 
B, C, D are analyzed and compared to a predetermined threshold in order to evaluate the 
effectiveness of the frame relay CIR policy implemented by the policy engine. A 
detemiination is then made (1720) as to whether the frame relay CIR policy is effective in 
maintaining the number of dropped packets on each or any of the respective links below the 
predetemiined threshold value. If it is determined that the current frame relay CIR policy is 
effective in maintaining the number of dropped packets on each of the respective links below 
a predetermined threshold, the quality monitor system 1662 may wait (1722) a specified time 
interval (e.g., 0-30 minutes) before re-evaluating the effectiveness of the current frame relay 
CIR policy by analyzing newly updated information relating to the number of packets 
dropped at each of the respective links. 

However, contrary to the Official Action, none of the data monitoring and analysis of 
these, or any other, passage of Nataraian relates to Appellants claimed executing a modeling 
algorithm that produces a model representing the historical data, analyzing said model, and 
configuring a video teleconferencing network based on said analysis. That is, for the 

Nataraian, column 31, lines 33-57. 
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reasons previously presented, Nataraian does not monitor or use Appellants' claimed 
historical data. Also, the monitored, stored and analyzed event data of Nataraian is not used 
for configuring a video teleconferencing network. Instead, the data is used to assess the 
viability of a current frame relay CIR policy. Nothing in Natarajan discusses configuring or 
reconfiguring a video teleconferencing network based on the event data. 



CONCLUSION 

Appellants have considered Evans , and submit Evans does not cure the deficiencies of 
Natarajan and Yates . As none of the cited prior art, individually or in combination, disclose 
or suggest all the elements of independent Claims 1,11 and 20, Applicants submit the 
inventions defined by Claims 1,11 and 20, and all claims depending therefrom, are not 
rendered obvious by the asserted references for at least the reasons stated above. Thus, 
Appellants request that the rejections applied under 35 U.S.C. § 103(a) to Claims 1,11 and 20 
be reversed for the above-noted reasons. 



Respectfiilly submitted, 

OBLON, SPIVAK, McCLELLAND, 
MAIER & NEUSTADT, P.C. 
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MPEP § 2142 . .the prior art reference (or references when conibined) must teach or suggest all the claim 
limitations. The teaching or suggestion to make the claimed conibination and the reasonable expectation of 
success must both be found in the prior art, and not based on applicant's disclosure. In re Vaeck, 947 F.2d 488, 
20 USPQ2d 1438 (Fed. Cir. 1991)." 
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VIII. CLAIMS APPENDIX 

Claim 1 : A method for modeling video teleconferencing network reliability, the 
method comprising: 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data referenced to 
video teleconferencing equipment vendor or model identification information; 

executing a modeling algorithm that produces a model representing the historical 

data; 

analyzing the model to identify characteristics associated with imdesirable outcomes 
for the video conferences; and 

configuring a video teleconferencing network to avoid at least one of the identified 
characteristics associated with undesirable outcomes. 

Claim 2: The method of Claim 1, wherein the operation of executing a modeling 
algorithm that produces a model comprise executing a decision tree algorithm. 

Claim 3: The method of Claim 2, wherein the operation of executing a decision tree 
algorithm comprises executing an IDS -based algorithm. 

Claim 4: The method of Claim 1, fiirther comprising conducting a new video 
conference with the video teleconferencing network configured to avoid at least one of the 
identified characteristics associated with undesirable outcomes. 

Claim 5: The method of Claim 4, fiirther comprising: 
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updating the historical data to create new historical data that includes values 
representing characteristics of the new video conference; 

executing the modeling algorithm to produce a new model representing the new 
historical data; 

analyzing the new model to produce a result; and 

reconfiguring the video teleconferencing network according to the result. 
Claim 6: The method of Claim 1, further comprising: 

evaluating the model to determine whether the model provides a desired level of 
efficacy; and 

in response to determining that the model does not provide a desired level of efficacy, 
using a different modeling algorithm to produce a different model. 

Claim 7: The method of Claim 1, wherein: 

the method fiirther comprises building a training set firom the historical data; 
the operation of executing the modeling algorithm comprises applying the modeling 
algorithm to the training set; and 

the operation of analyzing the model comprises: 
deriving a rule set firom the model; and 

analyzing the rule set to identify the characteristics associated with undesirable 
outcomes for the video conferences. 

Claim 8: The method of Claim 7, wherein: 

the historical data includes attribute values for attributes of each video conference and 
an outcome value representing an outcome for each video conference; and 
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the operation of applying the modeling algorithm to the training set comprises: 

using the outcome values as categorical attributes for the modeling algorithm; and 

using the attribute values as non-categorical attributes for the modeling algorithm. 

Claim 9: The method of Claim 7, wherein: 

the operation of obtaining historical data for multiple video conferences comprises 
obtaining a first endpoint identifier, a first endpoint vendor, a second endpoint identifier, a 
second endpoint vendor, and an outcome value for the multiple video conferences; 

the operation of building a training set comprises including the first endpoint 
identifier, the first endpoint vendor, the second endpoint identifier, the second endpoint 
vendor, and the outcome value for the multiple video conferences in the training set; and 

the operation of executing the modeling algorithm comprises using the first endpoint 
identifier, the first endpoint vendor, the second endpoint identifier, the second endpoint 
vendor, and the outcome value for the multiple video conferences to produce the model. 

Claim 10: The method of Claim 7, wherein: 

the training set includes values representing a first set of attributes; and 
the method further comprises: 

evaluating the model to determine whether the model provides a desired level of 
efficacy; 

in response to determining that the model does not provide a desired level of efficacy, 
building a different training set that includes a different set of attributes; and 

applying the modeling algorithm to the different training set to produce a different 

model. 
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Claim 11 : A tangible computer program product for modeling video teleconferencing 

network reliability, the tangible computer program product comprising: 

a tangible computer-usable medium; and 

computer instructions encoded in the tangible computer-usable mediimi, wherein the 
computer instructions, when executed, cause a data processing system to perform operations 
comprising: 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data referenced to 
vendor or model identification information; and 

executing a modeling algorithm that produces a model representing the historical data, 
such that the model can be analyzed to identify one or more opportunities for improving 
reUability of a video teleconferencing network. 

Claim 12: The tangible computer program product of Claim 11, wherein the 
computer instmctions cause the data processing system to perform further operations 
comprising: 

outputting results that reveal at least one of the opportunities for improving reliability 
of the video teleconferencing network, such that a user can reconfigure the video 
teleconferencing network, based on the results, to improve reliability of the video 
teleconferencing network. 

Claim 1 3 : The tangible computer program product of Claim 1 1 , wherein the 
computer instructions cause the data processing system to perform further operations 
comprising: 
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analyzing the model to identify the one or more opportunities for improving reliability 
of the video teleconferencing network; and 

automatically reconfiguring the video teleconferencing network, based on the 
identified opportunities, to improve reliability of the video teleconferencing network. 

Claim 14: The tangible computer program product of Claim 11, wherein: 
the operation of executing a modeling algorithm that produces a model comprises 
executing a decision tree algorithm. 

Claim 15: The tangible computer program product of Claim 1 1, wherein: 
the operation of executing the decision tree algorithm comprises executing an ID3- 
based algorithm. 

Claim 16: The tangible computer program product of Claim 1 1, wherein the 
computer instructions cause the data processing system to perform further operations 
comprising: 

updating the historical data to create new historical data that includes values 
representing characteristics of a new video conference; 

executing the modeling algorithm to produce a new model representing the new 
historical data; 

analyzing the new model to produce a result; and 

reconfiguring the video teleconferencing network according to the result to improve 
reliability of the video teleconferencing network. 
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Claim 17: The tangible computer program product of Claim 11, wherein the 
computer instructions cause the data processing system to perform further operations 
comprising: 

building a training set from the historical data; 

executing the modeling algorithm by applying the modeling algorithm to the training 
set; and 

deriving a rule set from the model, such that the one or more opportunities for 
improving reliability of a video teleconferencing network can be identified by reference to 
the rule set. 

Claim 18: The tangible computer program product of Claim 17, wherein: 
the historical data includes attribute values for attributes of each video conference and 
an outcome value representing an outcome for each video conference; 

the modeling algorithm uses the outcome values as categorical attributes; and 
the modeling algorithm uses the attribute values as non-categorical attributes. 

Claim 19: The tangible computer program product of Claim 17, wherein: 

the computer instructions cause the data processing system to obtain a first endpoint 

identifier, a first endpoint vendors a second endpoint identifier, a second endpoint vendor, 

and an outcome value for the multiple video conferences; 

the computer instructions cause the first endpoint identifier, the first endpoint vendor, 

the second endpoint identifier, the second endpoint vendor, and the outcome value for the 

multiple video conferences to, be stored in the training set; and 
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the modeling algorithm uses the fiat endpoint identifier, the first endpoint vendor, the 
second endpoint identifier, the second endpoint vendor, and the outcome value for the 
multiple video conferences to produce the model. 

Claim 20: A data processing system for modeling video teleconferencing network 
reliability, the data processing system comprising: 
one or more processing units; 

a tangible computer-usable medium in communication with the one or more 
processing units; and 

computer instructions encoded in the tangible computer-usable medium which, when 
executed by the one or more processing xmits, cause the data processing system to perform 
operations comprising: 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data referenced to 
vendor or model identification information; and 

executing a modeling algorithm that produces a model representing the historical data, 
such that the model can be analyzed to identify one or more opportunities for improving 
reliability of a video teleconferencing network. 
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IX. EVIDENCE APPENDIX 



Not applicable. 
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X. RELATED PROCEEDINGS APPENDIX 



Not applicable. 
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